セルフマネージド OpenShift (Red Hat OpenShift Platform Plus、Red Hat OpenShift Container Platform、Red Hat OpenShift Kubernetes Engine、Red Hat OpenShift Virtualization Engine) は、64 ビットの Red Hat Enterprise Linux が認定およびサポートされている場所ならどこでも使用できます。こちらのドキュメントを参照して、OpenShift のデプロイ方法とサポートされているインフラストラクチャのタイプの詳細をご確認ください。
セルフマネージド OpenShift ソフトウェアのエディション：
- Red Hat OpenShift Kubernetes Engine：エンタープライズ向けのハイブリッドクラウドの Kubernetes ランタイムエンジンであり、アプリケーションをデプロイおよび実行するための Red Hat OpenShift のコア機能を提供します。データセンター、パブリッククラウド、またはエッジ環境にインストールして管理します。
- Red Hat OpenShift Container Platform：エンタープライズ向けのハイブリッドクラウドの Kubernetes プラットフォームであり、アプリケーションを構築、デプロイ、実行するためのフル機能を備えています。データセンター、パブリッククラウド、およびエッジ環境にインストールして管理します。
- Red Hat OpenShift Platform Plus：単一のハイブリッドクラウド・プラットフォームで、複数のクラスタおよびクラウド環境にわたり、インテリジェントなアプリケーションを大規模に構築、デプロイ、実行、管理できます。セキュリティ、管理性、自動化に関して複数のレイヤーを備えており、ソフトウェア・サプライチェーン全体で一貫性を提供します。OpenShift Platform Plus サブスクリプションは、x86 ベースのクラスタでのみ使用できます。
- Red Hat OpenShift Virtualization Engine：Red Hat OpenShift とオープンソースのカーネルベースの仮想マシン (KVM) ハイパーバイザーに基づく、ベアメタルのみの仮想化インフラストラクチャ製品です。VM のデプロイ、管理、拡張のための信頼性の高いエンタープライズグレードのソリューションを提供することを目的として構築されています。OpenShift 機能のサブセットであるこの OpenShift エディションは、仮想マシンのみのワークロードを対象とし、コンテナではインフラストラクチャ・サービスのみがサポートされます (つまり、エンドユーザー・アプリケーション・コンテナはサポートされません)。
サブスクリプションの種類
セルフマネージド OpenShift には 2 種類のサブスクリプション (コアペアとベアメタルソケットペア) があり、各サブスクリプションでは 2 つのサポートレベルが利用できます。
環境内のコンピュートノードには、コンピュートノードのサブスクリプションが必要です。これらは、コアペアまたはベアメタルソケットペアによってエンタイトルメントが与えられます。
- コアペア (2 つのコアまたは 4 つの vCPU)
- サブスクリプション・オプションは、OpenShift Kubernetes Engine、OpenShift Container Platform、OpenShift Platform Plus で利用できます。コアペアのサブスクリプションは OpenShift Virtualization Engine には適用されません。
- CPU コアにエンタイトルメントを付与する場合は、コアペア・サブスクリプションを使用してエンタイトルメントを付与する、すべての OpenShift クラスタで実行されているすべての OpenShift コンピュートノードにわたる物理コアまたは vCPU の合計数をカウントします。
- 標準の 8x5 またはプレミアムの 24x7 のサポート SLA が利用できます。
- ベアメタルソケットペア (1 - 2 ソケット、合計最大 128 コア)
- このサブスクリプション・オプションは、すべてのセルフマネージド OpenShift エディションで利用でき、OpenShift Virtualization Engine の唯一のオプションです。
- このサブスクリプションは、OpenShift がハードウェアに直接インストールされる x86 および ARM ベアメタル物理ノードでのみ使用できます。サードパーティのハイパーバイザーは許可されません。
- これは「仮想データセンター」サブスクリプション (単一のサブスクリプションで任意のハイパーバイザーホストに VM ゲスト・オペレーティングシステム (OS) を無制限にインストールできる仮想データセンター用 Red Hat Enterprise Linux など) ではありません 。
- 標準の 8x5 またはプレミアムの 24x7 のサポート SLA が利用できます。
- 2 ソケットを超える、または 128 コアを超えるベアメタルサーバーの場合はスタックすることができますが、1 つのサブスクリプションで複数のベアメタルサーバーをカバーすることはできません。
さらに、環境内のアクセラレーターに対して Red Hat AI Accelerator サブスクリプションが必要になります。
- AI Accelerator (1 アクセラレーター)
- このサブスクリプションは、AI ワークロードの演算アクセラレーションを提供する、CPU パッケージの一部ではなく個別のアドオンであるアクセラレーターカード (GPU、TPU、NPU、FPGA、DPU など) に必要です。
- Red Hat OpenShift のエディションに関係なく、各物理 AI アクセラレーターに同じサブスクリプションが使用されます。
- Red Hat OpenShift と OpenShift AI の両方がクラスタにインストールされている場合は、単一の AI Accelerator サブスクリプションで十分です。
- アクセラレーター機能が演算アクセラレーションに使用されていない限り、このサブスクリプションは必要ありません。たとえば、ネットワーク・アクセラレーションのためだけに SmartNIC として使用する DPU (DPU に未使用のアドレス指定可能な ARM コアがある場合でも)、または AI アクセラレーションではなくグラフィックスのレンダリングに使用される GPU などです。
- 標準の 8x5 またはプレミアムの 24x7 のサポート SLA が利用できます。SLA は、サポートするコアペアまたはベアメタルソケットペアのサブスクリプションの SLA と一致する必要があります。
コアペアのサブスクリプションを選択するケース
セルフマネージド OpenShift をパブリッククラウド・ハイパースケーラーにデプロイする場合や、サービスとしてのインフラストラクチャ (IaaS) のプライベートクラウド内にデプロイする場合、または VMware vSphere、Red Hat OpenStack® Platform、Nutanix などのハイパーバイザーにデプロイする場合は、コアペア・サブスクリプションを選択することが最も多くなります。
コアペア・サブスクリプションにより、物理サーバーにサブスクリプションを適用する必要がなくなり、必要なときにいつでもどこでも Pod をハイブリッドクラウド全体に自由にデプロイできるようになります。
ベアメタルサーバーまたはデバイス (ハイパーバイザーなし) でコアペア・サブスクリプションを使用することもできます。注意が必要なのは、コンピュート Pod の密度によっては、ベアメタルソケットペアのサブスクリプションのほうがコスト効率が高くなる場合があることです。
OpenShift Virtualization Engine を専用の仮想化プラットフォームとして使用する場合に選択できるのは、ハイパーバイザー自体のためのベアメタル・ソケットペア・サブスクリプションに加えて、コアペア・サブスクリプションを使用して VM 上の OpenShift コンテナにエンタイトルメントを付与することです。セルフマネージド OpenShift のコアペア・サブスクリプションを個別に購入し、この環境内の VM に割り当てることができます。これはつまり、アプリケーションを購入してそれを VM として実行するのと同様です。この場合、コアの密度が高いと、セルフマネージド OpenShift のベアメタル・ソケットペア・モデルに切り替えたほうがコスト効率が高くなる場合があります。こちらのモデルでは、ベアメタルサーバー上の OpenShift コンテナが無制限となり、OpenShift VM でのそれらのコンテナの実行がサポートされるからです。
コアペア・サブスクリプションは、OpenShift クラスタ全体ですべての OpenShift コンピュートノードをカバーできるように分散することができます。たとえば、100 個のコアペア Red Hat OpenShift Platform Plus サブスクリプションで 200 コア (400 vCPU) がカバーされますが、これらはハイブリッドクラウド環境全体の実行中のすべての OpenShift クラスタにわたり、任意の数のコンピュートノードで使用できます。
ベアメタルソケットペアのサブスクリプションを選択するケース
ベアメタルソケットペアのサブスクリプションは、データセンター内またはサポートされているベアメタルオファリング上のホスト型プライベートクラウド内で、あるいはサポートされているベアメタルオファリング上のハイパースケーラーを使用して、専用の物理サーバーにデプロイされた OpenShift コンピュートノードのためのオプションです。ベアメタルソケットペアのサブスクリプションは、OpenShift Virtualization Engine の唯一のオプションです。また、もう一方のセルフマネージド OpenShift エディションで OpenShift Virtualization 機能をサポートするために必要です。
ベアメタルソケットペアのサブスクリプションごとに、ソケットペア全体で最大 128 個の物理コアにエンタイトルメントが付与されます。ベアメタル・サブスクリプションは、合計 128 コアを超えるソケットペアと、2 つ以上のソケットペアを持つ物理サーバーの両方をカバーするためにスタックできます。
物理サーバーにエンタイトルメントを付与するには、そのサーバー内のソケットまたは物理コアの総数 (どちらか大きい方) に応じて、1 つ以上のサブスクリプションをスタックします。たとえばサーバーに、各 CPU に 48 コアを備えた 2 つのソケットがあり、合計 96 コアがあるとします。このサーバーには 1 - 2 個のソケットがあり、コア数が 128 未満であるため、1 つのサブスクリプションが必要です。また、2 つのソケットと合計 192 のコアを持つサーバーの場合は、2 つのサブスクリプションが必要です。1 つのサブスクリプションがカバーするのは最大 128 コアなので、192 コアをカバーするには 2 つのサブスクリプションが必要になります。それぞれ 1 つのソケットがある 2 台のサーバーをカバーするために、または別々のサーバーのコアをカバーするために、単一のベアメタルソケットペアのサブスクリプションを複数の物理ホストに分割することはできません。
ソケットベースのエンタイトルメントを使用する各物理ベアメタルサーバーは、Kubernetes アーキテクチャの性質により、単一の OpenShift ノードとしてのみ使用できます。Kubernetes の各ノードは 1 つのクラスタにのみ属することができるからです。つまり、ベアメタルサーバー上のすべてのコンテナは同じクラスタに属することになります。これは、OpenShift Virtualization (各ワークロードが完全な VM を実行している) のようなリソースを大量に消費するワークロードには適していますが、他のワークロードには適していない可能性があります。OpenShift は単一ノード上で最大 2,500 個のコンテナをサポートしますが、パフォーマンスやアーキテクチャ上の理由から、異なるノードまたは異なるクラスタ間でコンテナを分割したい場合があります。これは、仮想化を使用してベアメタルサーバー上に個別のコンピュートノードを作成しない限り不可能です。
コンテナの一般的なデプロイメントモデルは、それぞれコンテナ数が少ない多数のクラスタを構築することです。このモデルはハイパースケーラー環境において一般的であり、データセンターでは、ハイパーバイザーを使用して、コンテナがデプロイされるコンピュートノードとなる VM を作成することで実現できます。VMware vSphere、Red Hat OpenStack Platform、Nutanix などのハイパーバイザーの場合は、VM にデプロイされた OpenShift 向けにコアペア・サブスクリプションを使用する必要があります。
ベアメタルにデプロイされ、エンタイトルメントのあるソケットペアのサブスクリプションを持つ OpenShift Kubernetes Engine、OpenShift Container Platform、OpenShift Platform Plus クラスタには、OpenShift Virtualization と、それらにデプロイされる同じ製品タイプの仮想 OpenShift クラスタのサブスクリプションを含めます。これは、たとえばベアメタル OpenShift Container Platform クラスタにデプロイされた仮想 OpenShift クラスタが、ホストしているベアメタルクラスタから OpenShift Container Platform サブスクリプションを継承することを意味します。
重要な注意事項は、OpenShift Virtualization Engine サブスクリプションにはコンテナ化されたアプリケーション・インスタンスのサポートが含まれていないことです。例外は、以下の OpenShift Virtualization Engine セクションで定義されているインフラストラクチャ・ワークロードです。 OpenShift Virtualization Engine を使用して独自のコンテナ化されたアプリケーションのワークロードを実行したい場合は、セルフマネージド OpenShift のコアペア・サブスクリプションを使用して VM にエンタイトルメントを付与する必要があります。または、より高い密度では、セルフマネージド OpenShift Kubernetes Engine、OpenShift Container Platform、または OpenShift Platform Plus にベアメタルソケットペアのサブスクリプションを購入することを選択できます。これにより、コンテナベースのアプリケーションをベアメタルクラスタ上でネイティブに実行できる、または前の段落で説明したように仮想クラスタがサブスクリプションを継承できます。
同じクラスタ内で OpenShift 製品タイプを混在させることはできません。すべてのノードは、同じ OpenShift Virtualization Engine、OpenShift Kubernetes Engine、OpenShift Container Platform、または OpenShift Platform Plus 製品タイプを使用してサブスクリプションを購入する必要があります。ただし、単一クラスタ内でコアペア・サブスクリプションとソケットペア・サブスクリプションを使用することはできます。たとえば、VM をホストするためのいくつかの OpenShift Virtualization Engine ノードと、コンテナ化されたアプリケーションおよび仮想 OpenShift インスタンスをホストするために OpenShift Platform Plus を使用してサブスクライブされている他のノードを、単一のベアメタルクラスタに含めることはできません。
AI Accelerator サブスクリプションのカウント方法
最近では、特定の計算ワークロードの高速実行が可能な特定のハードウェア・テクノロジーが市場に登場しています。これらのタイプのハードウェアデバイスは、Red Hat の一部のコンテンツではアクセラレーターまたは AI アクセラレーターと総称されます。最新のサーバーで利用できるハードウェアデバイスには、GPU、TPU、ASIC、NPU、FPGA など (これらに限定されません)、アクセラレーターとして分類できるいくつかの種類があります。
これらのアクセラレーターは通常、サーバーの PCI (Peripheral Component Interconnect) スロットを占有するカード、ボード、またはその他の物理デバイスです。これはほとんどの場合、アクセラレーターベンダーから購入したユニット数です。たとえば、ベンダーが「8 つの GPU を搭載している」としているサーバーの場合、これはほとんどの場合、8 つの物理アクセラレーターユニットを意味します。
各 AI Accelerator サブスクリプションは、1 つの物理アクセラレーターデバイスをカバーします。たとえば、AI Accelerator のサブスクリプションだけに焦点を当てると、次のようになります。
- 4 つの物理 GPU デバイスを備えた物理コンピュートノードには、コンピュートノードをカバーする CPU コアペアまたはソケットペアのサブスクリプションに加えて、4 つの AI Accelerator サブスクリプションが必要になります。
- 複数の vGPU として VM に提示される、1 つの物理 GPU デバイスを備えた単一の仮想コンピュートノードでは、仮想アクセラレーターではなく物理アクセラレーターに基づいてカウントされるため、1 つの AI Accelerator サブスクリプションが必要になります。
アクセラレーターは、コンピュート・ワークロードの実行に使用される場合にのみカウントされます。ワークロードの主な目的が、ユーザーの画面上にほぼリアルタイムでアクティブにピクセルを描画したり、ネットワーク上でデータを移動したりすることではない場合、そのワークロードはコンピュート・ワークロードとみなされます。
この区別は重要です。VFX (視覚効果) およびストリーミング・アプリケーションでは GPU やその他のアクセラレーター・ハードウェアが使用される場合がありますが、これらの場合の主な目的は画面上にピクセルを描画することだからです。場合によっては、ネットワーク上でのデータの移動 (ネットワーク機能専用のデータ処理ユニットなど) が主な機能の場合がありますが、これもコンピュートとはみなされません。
コンピュート・ワークロードの例には以下が含まれます。
- Java、Python、Perl などの従来のソフトウェア・アプリケーション
- LLM またはその他の処理負荷の高いソフトウェア
- データサイエンスモデルのトレーニングとチューニング
- タンパク質フォールディングや流体力学などの科学モデリングと物理シミュレーション。
